જાવાસ્ક્રિપ્ટમાં ટેસ્ટ-ડ્રિવન ડેવલપમેન્ટ: વૈશ્વિક ડેવલપર્સ માટે એક વ્યાપક માર્ગદર્શિકા

આ દૃશ્યની કલ્પના કરો: તમને એક મોટી, લેગસી સિસ્ટમમાં કોડના એક મહત્ત્વપૂર્ણ ભાગમાં ફેરફાર કરવાનું કામ સોંપવામાં આવ્યું છે. તમને એક પ્રકારનો ડર લાગે છે. શું તમારા ફેરફારથી બીજું કંઈક બગડી જશે? તમે કેવી રીતે ખાતરી કરી શકો કે સિસ્ટમ હજુ પણ હેતુ મુજબ કામ કરે છે? પરિવર્તનનો આ ડર સોફ્ટવેર ડેવલપમેન્ટમાં એક સામાન્ય સમસ્યા છે, જે ઘણીવાર ધીમી પ્રગતિ અને નાજુક એપ્લિકેશનો તરફ દોરી જાય છે. પરંતુ શું જો સોફ્ટવેરને આત્મવિશ્વાસ સાથે બનાવવાનો કોઈ રસ્તો હોત, એક એવી સુરક્ષા જાળ બનાવવી જે ભૂલોને ઉત્પાદનમાં પહોંચતા પહેલા જ પકડી લે? આ ટેસ્ટ-ડ્રિવન ડેવલપમેન્ટ (TDD) નું વચન છે.

TDD માત્ર એક ટેસ્ટિંગ ટેકનિક નથી; તે સોફ્ટવેર ડિઝાઇન અને ડેવલપમેન્ટ માટેનો એક શિસ્તબદ્ધ અભિગમ છે. તે પરંપરાગત "પહેલા કોડ લખો, પછી ટેસ્ટ કરો" મોડેલને ઉલટાવી દે છે. TDD સાથે, તમે પ્રોડક્શન કોડ લખતા પહેલા એક ટેસ્ટ લખો છો જે નિષ્ફળ જાય છે. આ સરળ ઉલટાવાથી કોડની ગુણવત્તા, ડિઝાઇન અને જાળવણી પર ગહન અસરો પડે છે. આ માર્ગદર્શિકા વ્યાવસાયિક ડેવલપર્સના વૈશ્વિક પ્રેક્ષકો માટે રચાયેલ જાવાસ્ક્રિપ્ટમાં TDD ના અમલીકરણ પર એક વ્યાપક, વ્યવહારુ દ્રષ્ટિ પ્રદાન કરશે.

ટેસ્ટ-ડ્રિવન ડેવલપમેન્ટ (TDD) શું છે?

તેના મૂળમાં, ટેસ્ટ-ડ્રિવન ડેવલપમેન્ટ એ એક વિકાસ પ્રક્રિયા છે જે ખૂબ જ ટૂંકા વિકાસ ચક્રના પુનરાવર્તન પર આધાર રાખે છે. સુવિધાઓ લખીને પછી તેનું પરીક્ષણ કરવાને બદલે, TDD એ વાત પર આગ્રહ રાખે છે કે પહેલા ટેસ્ટ લખવામાં આવે. આ ટેસ્ટ અનિવાર્યપણે નિષ્ફળ જશે કારણ કે સુવિધા હજુ અસ્તિત્વમાં નથી. પછી ડેવલપરનું કામ તે ચોક્કસ ટેસ્ટને પાસ કરવા માટે શક્ય તેટલો સરળ કોડ લખવાનું છે. એકવાર તે પાસ થઈ જાય, પછી કોડને સાફ અને સુધારવામાં આવે છે. આ મૂળભૂત લૂપને "રેડ-ગ્રીન-રિફેક્ટર" ચક્ર તરીકે ઓળખવામાં આવે છે.

TDD ની લય: રેડ-ગ્રીન-રિફેક્ટર

આ ત્રણ-પગલાંનું ચક્ર TDD નું હૃદય છે. આ લયને સમજવી અને તેનો અભ્યાસ કરવો એ ટેકનિકમાં નિપુણતા મેળવવા માટે મૂળભૂત છે.

• 🔴 રેડ — એક નિષ્ફળ ટેસ્ટ લખો: તમે નવી ફંક્શનાલિટીના ટુકડા માટે એક સ્વચાલિત ટેસ્ટ લખીને શરૂઆત કરો છો. આ ટેસ્ટે વ્યાખ્યાયિત કરવું જોઈએ કે તમે શું કોડ પાસેથી કરાવવા માંગો છો. કારણ કે તમે હજી સુધી કોઈ અમલીકરણ કોડ લખ્યો નથી, આ ટેસ્ટ નિષ્ફળ જવાની ખાતરી છે. નિષ્ફળ ટેસ્ટ એ સમસ્યા નથી; તે પ્રગતિ છે. તે સાબિત કરે છે કે ટેસ્ટ યોગ્ય રીતે કામ કરી રહ્યો છે (તે નિષ્ફળ થઈ શકે છે) અને આગલા પગલા માટે એક સ્પષ્ટ, નક્કર લક્ષ્ય નિર્ધારિત કરે છે.
• 🟢 ગ્રીન — પાસ થવા માટે સૌથી સરળ કોડ લખો: તમારું લક્ષ્ય હવે એકમાત્ર છે: ટેસ્ટને પાસ કરવો. તમારે ટેસ્ટને રેડમાંથી ગ્રીનમાં ફેરવવા માટે જરૂરી ઉત્પાદન કોડની સંપૂર્ણ લઘુત્તમ માત્રા લખવી જોઈએ. આ કદાચ અતાર્કિક લાગી શકે; કોડ કદાચ સુંદર કે કાર્યક્ષમ ન હોય. તે ઠીક છે. અહીં ધ્યાન ફક્ત ટેસ્ટ દ્વારા વ્યાખ્યાયિત જરૂરિયાતને પૂર્ણ કરવા પર છે.
• 🔵 રિફેક્ટર — કોડમાં સુધારો કરો: હવે જ્યારે તમારી પાસે પાસિંગ ટેસ્ટ છે, ત્યારે તમારી પાસે એક સુરક્ષા જાળ છે. તમે કાર્યક્ષમતાને તોડવાના ડર વિના તમારા કોડને વિશ્વાસપૂર્વક સાફ અને સુધારી શકો છો. આ તે સ્થાન છે જ્યાં તમે કોડની ખામીઓને દૂર કરો છો, ડુપ્લિકેશન દૂર કરો છો, સ્પષ્ટતામાં સુધારો કરો છો અને પ્રદર્શનને શ્રેષ્ઠ બનાવો છો. તમે રિફેક્ટરિંગ દરમિયાન કોઈપણ સમયે તમારી ટેસ્ટ સ્યુટ ચલાવી શકો છો જેથી ખાતરી કરી શકાય કે તમે કોઈ રિગ્રેશન દાખલ નથી કર્યા. રિફેક્ટરિંગ પછી, બધા ટેસ્ટ હજુ પણ ગ્રીન હોવા જોઈએ.

એકવાર એક નાના ફંક્શનાલિટી માટે ચક્ર પૂર્ણ થઈ જાય, પછી તમે આગલા ભાગ માટે નવા નિષ્ફળ ટેસ્ટ સાથે ફરીથી શરૂઆત કરો છો.

TDD ના ત્રણ નિયમો

રોબર્ટ સી. માર્ટિન (જેમને "અંકલ બોબ" તરીકે પણ ઓળખવામાં આવે છે), જે એજાઈલ સોફ્ટવેર ચળવળના મુખ્ય વ્યક્તિ છે, તેમણે ત્રણ સરળ નિયમો વ્યાખ્યાયિત કર્યા છે જે TDD શિસ્તને સંહિતાબદ્ધ કરે છે:

1. તમારે કોઈ પણ પ્રોડક્શન કોડ ત્યાં સુધી નથી લખવાનો જ્યાં સુધી તે નિષ્ફળ યુનિટ ટેસ્ટને પાસ ન કરાવે.
2. તમારે યુનિટ ટેસ્ટને નિષ્ફળ થવા માટે પૂરતા કરતાં વધુ લખવાનો નથી; અને કમ્પાઈલેશન નિષ્ફળતાઓ પણ નિષ્ફળતા છે.
3. તમારે એક નિષ્ફળ યુનિટ ટેસ્ટને પાસ કરવા માટે પૂરતા કરતાં વધુ પ્રોડક્શન કોડ લખવાનો નથી.

આ નિયમોનું પાલન કરવાથી તમે રેડ-ગ્રીન-રિફેક્ટર ચક્રમાં જોડાઓ છો અને ખાતરી કરે છે કે તમારો 100% પ્રોડક્શન કોડ એક ચોક્કસ, પરીક્ષણ કરેલ જરૂરિયાતને સંતોષવા માટે લખાયેલ છે.

તમારે TDD શા માટે અપનાવવું જોઈએ? ગ્લોબલ બિઝનેસ કેસ

જ્યારે TDD વ્યક્તિગત ડેવલપર્સને અપાર લાભો પ્રદાન કરે છે, ત્યારે તેની સાચી શક્તિ ટીમ અને વ્યવસાય સ્તરે, ખાસ કરીને વૈશ્વિક સ્તરે વિતરિત વાતાવરણમાં સમજાય છે.

• આત્મવિશ્વાસ અને વેગમાં વધારો: એક વ્યાપક ટેસ્ટ સ્યુટ સુરક્ષા જાળ તરીકે કામ કરે છે. આ ટીમોને આત્મવિશ્વાસ સાથે નવી સુવિધાઓ ઉમેરવા અથવા હાલની સુવિધાઓને રિફેક્ટર કરવાની મંજૂરી આપે છે, જે ઉચ્ચ ટકાઉ વિકાસ વેગ તરફ દોરી જાય છે. તમે મેન્યુઅલ રિગ્રેશન ટેસ્ટિંગ અને ડિબગીંગ પર ઓછો સમય અને મૂલ્ય પહોંચાડવા પર વધુ સમય વિતાવો છો.
• સુધારેલ કોડ ડિઝાઇન: પહેલા ટેસ્ટ લખવાથી તમને એ વિચારવા માટે મજબૂર કરે છે કે તમારા કોડનો ઉપયોગ કેવી રીતે થશે. તમે તમારા પોતાના API ના પ્રથમ ગ્રાહક છો. આ કુદરતી રીતે નાના, વધુ કેન્દ્રિત મોડ્યુલો અને ચિંતાઓના સ્પષ્ટ વિભાજન સાથે વધુ સારી રીતે ડિઝાઇન કરેલા સોફ્ટવેર તરફ દોરી જાય છે.
• જીવંત દસ્તાવેજીકરણ: જુદા જુદા સમય ઝોન અને સંસ્કૃતિઓમાં કામ કરતી વૈશ્વિક ટીમ માટે, સ્પષ્ટ દસ્તાવેજીકરણ નિર્ણાયક છે. એક સારી રીતે લખાયેલ ટેસ્ટ સ્યુટ એ જીવંત, એક્ઝેક્યુટેબલ દસ્તાવેજીકરણનું એક સ્વરૂપ છે. એક નવો ડેવલપર ટેસ્ટ વાંચીને સમજી શકે છે કે કોડનો એક ભાગ બરાબર શું કરવાનું છે અને તે વિવિધ પરિસ્થિતિઓમાં કેવી રીતે વર્તે છે. પરંપરાગત દસ્તાવેજીકરણથી વિપરીત, તે ક્યારેય જૂનું થઈ શકતું નથી.
• માલિકીનો કુલ ખર્ચ (TCO) ઓછો: વિકાસ ચક્રમાં વહેલા પકડાયેલી ભૂલો ઉત્પાદનમાં જોવા મળતી ભૂલો કરતાં અનેકગણી સસ્તી હોય છે. TDD એક મજબૂત સિસ્ટમ બનાવે છે જે સમય જતાં જાળવવામાં અને વિસ્તૃત કરવામાં સરળ હોય છે, જે સોફ્ટવેરના લાંબા ગાળાના TCO ને ઘટાડે છે.

તમારું જાવાસ્ક્રિપ્ટ TDD પર્યાવરણ સેટ કરવું

જાવાસ્ક્રિપ્ટમાં TDD સાથે પ્રારંભ કરવા માટે, તમારે કેટલાક સાધનોની જરૂર છે. આધુનિક જાવાસ્ક્રિપ્ટ ઇકોસિસ્ટમ ઉત્તમ પસંદગીઓ પ્રદાન કરે છે.

ટેસ્ટિંગ સ્ટેકના મુખ્ય ઘટકો

• ટેસ્ટ રનર: એક પ્રોગ્રામ જે તમારા ટેસ્ટને શોધે છે અને ચલાવે છે. તે માળખું (`describe` અને `it` બ્લોક્સ જેવું) પૂરું પાડે છે અને પરિણામોની જાણ કરે છે. Jest અને Mocha બે સૌથી લોકપ્રિય પસંદગીઓ છે.
• એસર્શન લાઇબ્રેરી: એક સાધન જે તમારો કોડ અપેક્ષા મુજબ વર્તે છે તેની ચકાસણી કરવા માટે ફંક્શન પ્રદાન કરે છે. તે તમને `expect(result).toBe(true)` જેવા નિવેદનો લખવા દે છે. Chai એક લોકપ્રિય સ્ટેન્ડઅલોન લાઇબ્રેરી છે, જ્યારે Jest માં તેની પોતાની શક્તિશાળી એસર્શન લાઇબ્રેરી શામેલ છે.
• મોકિંગ લાઇબ્રેરી: API કોલ્સ અથવા ડેટાબેઝ કનેક્શન્સ જેવી નિર્ભરતાઓના "નકલી" બનાવવા માટેનું એક સાધન. આ તમને તમારા કોડને અલગતામાં પરીક્ષણ કરવાની મંજૂરી આપે છે. Jest માં ઉત્તમ બિલ્ટ-ઇન મોકિંગ ક્ષમતાઓ છે.

તેની સરળતા અને ઓલ-ઇન-વન પ્રકૃતિ માટે, અમે અમારા ઉદાહરણો માટે Jest નો ઉપયોગ કરીશું. તે "ઝીરો-કન્ફિગરેશન" અનુભવ શોધી રહેલી ટીમો માટે એક ઉત્તમ પસંદગી છે.

Jest સાથે સ્ટેપ-બાય-સ્ટેપ સેટઅપ

ચાલો TDD માટે એક નવો પ્રોજેક્ટ સેટ કરીએ.

1. તમારા પ્રોજેક્ટને ઇનિશિયલાઇઝ કરો: તમારું ટર્મિનલ ખોલો અને નવી પ્રોજેક્ટ ડિરેક્ટરી બનાવો.

            mkdir js-tdd-project
cd js-tdd-project
npm init -y
            

              
                Copy
              
            
          

2. Jest ઇન્સ્ટોલ કરો: Jest ને તમારા પ્રોજેક્ટમાં ડેવલપમેન્ટ ડિપેન્ડન્સી તરીકે ઉમેરો.

            npm install --save-dev jest
            

              
                Copy
              
            
          

3. ટેસ્ટ સ્ક્રિપ્ટને કન્ફિગર કરો: તમારી `package.json` ફાઇલ ખોલો. `"scripts"` વિભાગ શોધો અને `"test"` સ્ક્રિપ્ટમાં ફેરફાર કરો. `"test:watch"` સ્ક્રિપ્ટ ઉમેરવાની પણ ખૂબ ભલામણ કરવામાં આવે છે, જે TDD વર્કફ્લો માટે અમૂલ્ય છે.

            "scripts": {
  "test": "jest",
  "test:watch": "jest --watchAll"
}
            

              
                Copy
              
            
          

`--watchAll` ફ્લેગ Jest ને કહે છે કે જ્યારે પણ કોઈ ફાઇલ સેવ થાય ત્યારે ટેસ્ટને આપમેળે ફરીથી ચલાવો. આ ત્વરિત પ્રતિસાદ પૂરો પાડે છે, જે રેડ-ગ્રીન-રિફેક્ટર ચક્ર માટે યોગ્ય છે.

બસ આટલું જ! તમારું પર્યાવરણ તૈયાર છે. Jest આપમેળે `*.test.js`, `*.spec.js` નામની ટેસ્ટ ફાઇલો અથવા `__tests__` ડિરેક્ટરીમાં સ્થિત ફાઇલોને શોધી કાઢશે.

પ્રેક્ટિસમાં TDD: એક `CurrencyConverter` મોડ્યુલ બનાવવું

ચાલો TDD ચક્રને એક વ્યવહારુ, વૈશ્વિક સ્તરે સમજી શકાય તેવી સમસ્યા પર લાગુ કરીએ: કરન્સી વચ્ચે નાણાંનું રૂપાંતર. અમે એક `CurrencyConverter` મોડ્યુલ સ્ટેપ બાય સ્ટેપ બનાવીશું.

પુનરાવર્તન 1: સરળ, નિશ્ચિત-દર રૂપાંતરણ

🔴 રેડ: પ્રથમ નિષ્ફળ ટેસ્ટ લખો

અમારી પ્રથમ જરૂરિયાત નિશ્ચિત દરનો ઉપયોગ કરીને એક કરન્સીમાંથી બીજી કરન્સીમાં ચોક્કસ રકમનું રૂપાંતર કરવાની છે. `CurrencyConverter.test.js` નામની નવી ફાઇલ બનાવો.

            // CurrencyConverter.test.js
const CurrencyConverter = require('./CurrencyConverter');

describe('CurrencyConverter', () => {
  it('should convert an amount from USD to EUR correctly', () => {
    // Arrange
    const amount = 10; // 10 USD
    const expected = 9.2; // Assuming a fixed rate of 1 USD = 0.92 EUR

    // Act
    const result = CurrencyConverter.convert(amount, 'USD', 'EUR');

    // Assert
    expect(result).toBe(expected);
  });
});
            

              
                Copy
              
            
          

હવે, તમારા ટર્મિનલમાંથી ટેસ્ટ વોચર ચલાવો:

            npm run test:watch
            

              
                Copy
              
            
          

ટેસ્ટ જોવાલાયક રીતે નિષ્ફળ જશે. Jest કંઈક આવું રિપોર્ટ કરશે `TypeError: Cannot read properties of undefined (reading 'convert')`. આ અમારી રેડ સ્થિતિ છે. ટેસ્ટ નિષ્ફળ જાય છે કારણ કે `CurrencyConverter` અસ્તિત્વમાં નથી.

🟢 ગ્રીન: પાસ થવા માટે સૌથી સરળ કોડ લખો

હવે, ચાલો ટેસ્ટને પાસ કરીએ. `CurrencyConverter.js` બનાવો.

            // CurrencyConverter.js
const rates = {
  USD: {
    EUR: 0.92
  }
};

const CurrencyConverter = {
  convert(amount, from, to) {
    return amount * rates[from][to];
  }
};

module.exports = CurrencyConverter;
            

              
                Copy
              
            
          

જેવી તમે આ ફાઇલ સેવ કરશો, Jest ટેસ્ટ ફરીથી ચલાવશે, અને તે ગ્રીન થઈ જશે. અમે ટેસ્ટની જરૂરિયાતને સંતોષવા માટે સંપૂર્ણ લઘુત્તમ કોડ લખ્યો છે.

🔵 રિફેક્ટર: કોડમાં સુધારો કરો

કોડ સરળ છે, પરંતુ આપણે પહેલેથી જ સુધારાઓ વિશે વિચારી શકીએ છીએ. નેસ્ટેડ `rates` ઓબ્જેક્ટ થોડો કઠોર છે. અત્યારે, તે પૂરતો સ્વચ્છ છે. સૌથી મહત્વની વાત એ છે કે આપણી પાસે એક ટેસ્ટ દ્વારા સુરક્ષિત કાર્યરત સુવિધા છે. ચાલો આગલી જરૂરિયાત પર આગળ વધીએ.

પુનરાવર્તન 2: અજાણી કરન્સીને હેન્ડલ કરવી

🔴 રેડ: અમાન્ય કરન્સી માટે એક ટેસ્ટ લખો

જો આપણે એવી કરન્સીમાં રૂપાંતર કરવાનો પ્રયાસ કરીએ જે આપણે જાણતા નથી તો શું થવું જોઈએ? તે કદાચ એક એરર ફેંકવી જોઈએ. ચાલો `CurrencyConverter.test.js` માં નવા ટેસ્ટમાં આ વર્તનને વ્યાખ્યાયિત કરીએ.

            // In CurrencyConverter.test.js, inside the describe block

it('should throw an error for unknown currencies', () => {
  // Arrange
  const amount = 10;

  // Act & Assert
  // We wrap the function call in an arrow function for Jest's toThrow to work.
  expect(() => {
    CurrencyConverter.convert(amount, 'USD', 'XYZ');
  }).toThrow('Unknown currency: XYZ');
});
            

              
                Copy
              
            
          

ફાઇલ સેવ કરો. ટેસ્ટ રનર તરત જ નવી નિષ્ફળતા બતાવે છે. તે રેડ છે કારણ કે અમારો કોડ એરર ફેંકતો નથી; તે `rates['USD']['XYZ']` ને એક્સેસ કરવાનો પ્રયાસ કરે છે, જેના પરિણામે `TypeError` આવે છે. અમારા નવા ટેસ્ટે આ ખામીને યોગ્ય રીતે ઓળખી છે.

🟢 ગ્રીન: નવો ટેસ્ટ પાસ કરો

ચાલો વેલિડેશન ઉમેરવા માટે `CurrencyConverter.js` માં ફેરફાર કરીએ.

            // CurrencyConverter.js
const rates = {
  USD: {
    EUR: 0.92,
    GBP: 0.80
  },
  EUR: {
    USD: 1.08
  }
};

const CurrencyConverter = {
  convert(amount, from, to) {
    if (!rates[from] || !rates[from][to]) {
      // Determine which currency is unknown for a better error message
      const unknownCurrency = !rates[from] ? from : to;
      throw new Error(`Unknown currency: ${unknownCurrency}`);
    }
    return amount * rates[from][to];
  }
};

module.exports = CurrencyConverter;
            

              
                Copy
              
            
          

ફાઇલ સેવ કરો. બંને ટેસ્ટ હવે પાસ થાય છે. અમે ગ્રીન પર પાછા આવી ગયા છીએ.

🔵 રિફેક્ટર: તેને સાફ કરો

અમારું `convert` ફંક્શન વધી રહ્યું છે. વેલિડેશન લોજિક ગણતરી સાથે મિશ્રિત છે. વાંચનીયતા સુધારવા માટે અમે વેલિડેશનને અલગ પ્રાઈવેટ ફંક્શનમાં કાઢી શકીએ છીએ, પરંતુ અત્યારે તે હજુ પણ વ્યવસ્થાપિત છે. મુખ્ય વાત એ છે કે આપણી પાસે આ ફેરફારો કરવાની સ્વતંત્રતા છે કારણ કે જો આપણે કંઈક તોડીશું તો અમારા ટેસ્ટ અમને જણાવશે.

પુનરાવર્તન 3: અસિંક્રોનસ રેટ ફેચિંગ

હાર્ડકોડિંગ રેટ્સ વાસ્તવિક નથી. ચાલો આપણા મોડ્યુલને (મોક કરેલ) બાહ્ય API માંથી રેટ્સ મેળવવા માટે રિફેક્ટર કરીએ.

🔴 રેડ: એક અસિંક ટેસ્ટ લખો જે API કોલને મોક કરે છે

પ્રથમ, આપણે આપણા કન્વર્ટરને પુનઃરચના કરવાની જરૂર છે. તે હવે એક ક્લાસ હોવો જોઈશે જેને આપણે ઇન્સ્ટેન્શિએટ કરી શકીએ, કદાચ API ક્લાયંટ સાથે. આપણે `fetch` API ને પણ મોક કરવાની જરૂર પડશે. Jest આને સરળ બનાવે છે.

ચાલો આપણી ટેસ્ટ ફાઇલને આ નવી, અસિંક્રોનસ વાસ્તવિકતાને સમાવવા માટે ફરીથી લખીએ. આપણે ફરીથી હેપી પાથનું પરીક્ષણ કરીને શરૂઆત કરીશું.

            // CurrencyConverter.test.js
const CurrencyConverter = require('./CurrencyConverter');

// Mock the external dependency
global.fetch = jest.fn();

beforeEach(() => {
  // Clear mock history before each test
  fetch.mockClear();
});

describe('CurrencyConverter', () => {
  it('should fetch rates and convert correctly', async () => {
    // Arrange
    // Mock the successful API response
    fetch.mockResolvedValueOnce({
      json: () => Promise.resolve({ rates: { EUR: 0.92 } })
    });

    const converter = new CurrencyConverter('https://api.exchangerates.com');
    const amount = 10; // 10 USD

    // Act
    const result = await converter.convert(amount, 'USD', 'EUR');

    // Assert
    expect(result).toBe(9.2);
    expect(fetch).toHaveBeenCalledTimes(1);
    expect(fetch).toHaveBeenCalledWith('https://api.exchangerates.com/latest?base=USD');
  });

  // We'd also add tests for API failures, etc.
});
            

              
                Copy
              
            
          

આ ચલાવવાથી રેડ નો દરિયો પરિણમશે. અમારો જૂનો `CurrencyConverter` ક્લાસ નથી, તેની પાસે `async` મેથડ નથી, અને તે `fetch` નો ઉપયોગ કરતું નથી.

🟢 ગ્રીન: અસિંક લોજિકનો અમલ કરો

હવે, ચાલો ટેસ્ટની જરૂરિયાતોને પહોંચી વળવા માટે `CurrencyConverter.js` ને ફરીથી લખીએ.

            // CurrencyConverter.js
class CurrencyConverter {
  constructor(apiUrl) {
    this.apiUrl = apiUrl;
  }

  async convert(amount, from, to) {
    const response = await fetch(`${this.apiUrl}/latest?base=${from}`);
    if (!response.ok) {
      throw new Error('Failed to fetch exchange rates.');
    }

    const data = await response.json();
    const rate = data.rates[to];

    if (!rate) {
      throw new Error(`Unknown currency: ${to}`);
    }

    // Simple rounding to avoid floating point issues in tests
    const convertedAmount = amount * rate;
    return parseFloat(convertedAmount.toFixed(2));
  }
}

module.exports = CurrencyConverter;
            

              
                Copy
              
            
          

જ્યારે તમે સેવ કરશો, ત્યારે ટેસ્ટ ગ્રીન થવો જોઈએ. નોંધ કરો કે અમે ફ્લોટિંગ-પોઇન્ટની અચોક્કસતાઓને હેન્ડલ કરવા માટે રાઉન્ડિંગ લોજિક પણ ઉમેર્યું છે, જે નાણાકીય ગણતરીઓમાં એક સામાન્ય સમસ્યા છે.

🔵 રિફેક્ટર: અસિંક કોડમાં સુધારો કરો

આ `convert` મેથડ ઘણું બધું કરી રહી છે: ફેચિંગ, એરર હેન્ડલિંગ, પાર્સિંગ અને ગણતરી. અમે આને એક અલગ `RateFetcher` ક્લાસ બનાવીને રિફેક્ટર કરી શકીએ છીએ જે ફક્ત API સંચાર માટે જવાબદાર હોય. અમારો `CurrencyConverter` પછી આ ફેચરનો ઉપયોગ કરશે. આ સિંગલ રિસ્પોન્સિબિલિટી પ્રિન્સિપલને અનુસરે છે અને બંને ક્લાસને ટેસ્ટ કરવા અને જાળવવા માટે સરળ બનાવે છે. TDD આપણને આ સ્વચ્છ ડિઝાઇન તરફ માર્ગદર્શન આપે છે.

સામાન્ય TDD પેટર્ન અને એન્ટી-પેટર્ન

જેમ જેમ તમે TDD નો અભ્યાસ કરશો, તેમ તમને એવી પેટર્ન જોવા મળશે જે સારી રીતે કામ કરે છે અને એવી એન્ટી-પેટર્ન કે જે ઘર્ષણનું કારણ બને છે.

અનુસરવા માટે સારી પેટર્ન

• એરેન્જ, એક્ટ, એસર્ટ (AAA): તમારા ટેસ્ટને ત્રણ સ્પષ્ટ ભાગોમાં ગોઠવો. તમારા સેટઅપને એરેન્જ કરો, ટેસ્ટ હેઠળના કોડને એક્ઝિક્યુટ કરીને એક્ટ કરો, અને પરિણામ સાચું છે તે એસર્ટ કરો. આ ટેસ્ટને વાંચવા અને સમજવામાં સરળ બનાવે છે.
• એક સમયે એક જ વર્તનનું પરીક્ષણ કરો: દરેક ટેસ્ટ કેસ એક જ, ચોક્કસ વર્તનની ચકાસણી કરતો હોવો જોઈએ. જ્યારે ટેસ્ટ નિષ્ફળ જાય ત્યારે શું તૂટ્યું તે સ્પષ્ટ થાય છે.
• વર્ણનાત્મક ટેસ્ટ નામોનો ઉપયોગ કરો: `it('test 1')` કરતાં `it('should throw an error if the amount is negative')` જેવું ટેસ્ટ નામ વધુ મૂલ્યવાન છે.

ટાળવા માટેની એન્ટી-પેટર્ન

• અમલીકરણની વિગતોનું પરીક્ષણ: ટેસ્ટ જાહેર API ("શું") પર ધ્યાન કેન્દ્રિત કરવું જોઈએ, ખાનગી અમલીકરણ ("કેવી રીતે") પર નહીં. ખાનગી મેથડનું પરીક્ષણ કરવાથી તમારા ટેસ્ટ બરડ બને છે અને રિફેક્ટરિંગ મુશ્કેલ બને છે.
• રિફેક્ટર સ્ટેપને અવગણવું: આ સૌથી સામાન્ય ભૂલ છે. રિફેક્ટરિંગ છોડવાથી તમારા પ્રોડક્શન કોડ અને તમારી ટેસ્ટ સ્યુટ બંનેમાં ટેકનિકલ દેવું થાય છે.
• મોટા, ધીમા ટેસ્ટ લખવા: યુનિટ ટેસ્ટ ઝડપી હોવા જોઈએ. જો તેઓ વાસ્તવિક ડેટાબેઝ, નેટવર્ક કોલ્સ અથવા ફાઇલસિસ્ટમ પર આધાર રાખે છે, તો તે ધીમા અને અવિશ્વસનીય બની જાય છે. તમારા યુનિટ્સને અલગ કરવા માટે મોક્સ અને સ્ટબ્સનો ઉપયોગ કરો.

વ્યાપક વિકાસ જીવનચક્રમાં TDD

TDD શૂન્યાવકાશમાં અસ્તિત્વમાં નથી. તે આધુનિક એજાઈલ અને ડેવઓપ્સ પદ્ધતિઓ સાથે સુંદર રીતે સંકલિત થાય છે, ખાસ કરીને વૈશ્વિક ટીમો માટે.

• TDD અને એજાઈલ: તમારા પ્રોજેક્ટ મેનેજમેન્ટ ટૂલમાંથી એક યુઝર સ્ટોરી અથવા સ્વીકૃતિ માપદંડ સીધા નિષ્ફળ ટેસ્ટની શ્રેણીમાં અનુવાદિત કરી શકાય છે. આ સુનિશ્ચિત કરે છે કે તમે બરાબર તે જ બનાવી રહ્યા છો જેની વ્યવસાયને જરૂર છે.
• TDD અને કન્ટીન્યુઅસ ઇન્ટિગ્રેશન/કન્ટીન્યુઅસ ડિપ્લોયમેન્ટ (CI/CD): TDD એક વિશ્વસનીય CI/CD પાઇપલાઇનનો પાયો છે. દર વખતે જ્યારે કોઈ ડેવલપર કોડ પુશ કરે છે, ત્યારે એક સ્વચાલિત સિસ્ટમ (જેમ કે GitHub Actions, GitLab CI, અથવા Jenkins) સમગ્ર ટેસ્ટ સ્યુટ ચલાવી શકે છે. જો કોઈ ટેસ્ટ નિષ્ફળ જાય, તો બિલ્ડ અટકાવી દેવામાં આવે છે, જે બગ્સને ઉત્પાદનમાં પહોંચતા અટકાવે છે. આ સમગ્ર ટીમને સમય ઝોનને ધ્યાનમાં લીધા વિના ઝડપી, સ્વચાલિત પ્રતિસાદ પૂરો પાડે છે.
• TDD વિરુદ્ધ BDD (બિહેવિયર-ડ્રિવન ડેવલપમેન્ટ): BDD એ TDD નું વિસ્તરણ છે જે ડેવલપર્સ, QA અને બિઝનેસ હિતધારકો વચ્ચેના સહયોગ પર ધ્યાન કેન્દ્રિત કરે છે. તે વર્તનને વર્ણવવા માટે કુદરતી ભાષાના ફોર્મેટ (ગિવન-વ્હેન-ધેન) નો ઉપયોગ કરે છે. ઘણીવાર, BDD ફીચર ફાઇલ અનેક TDD-શૈલીના યુનિટ ટેસ્ટના નિર્માણને પ્રેરિત કરશે.

નિષ્કર્ષ: TDD સાથે તમારી યાત્રા

ટેસ્ટ-ડ્રિવન ડેવલપમેન્ટ એ ટેસ્ટિંગ વ્યૂહરચના કરતાં વધુ છે—તે સોફ્ટવેર ડેવલપમેન્ટના આપણા અભિગમમાં એક પેરાડાઈમ શિફ્ટ છે. તે ગુણવત્તા, આત્મવિશ્વાસ અને સહયોગની સંસ્કૃતિને પ્રોત્સાહન આપે છે. રેડ-ગ્રીન-રિફેક્ટર ચક્ર એક સ્થિર લય પૂરી પાડે છે જે તમને સ્વચ્છ, મજબૂત અને જાળવી શકાય તેવા કોડ તરફ માર્ગદર્શન આપે છે. પરિણામી ટેસ્ટ સ્યુટ એક સુરક્ષા જાળ બની જાય છે જે તમારી ટીમને રિગ્રેશનથી બચાવે છે અને જીવંત દસ્તાવેજીકરણ જે નવા સભ્યોને ઓનબોર્ડ કરે છે.

શીખવાની પ્રક્રિયા મુશ્કેલ લાગી શકે છે, અને પ્રારંભિક ગતિ ધીમી લાગી શકે છે. પરંતુ ડિબગીંગ સમયમાં ઘટાડો, સુધારેલી સોફ્ટવેર ડિઝાઇન અને વધેલા ડેવલપર આત્મવિશ્વાસમાં લાંબા ગાળાના લાભો અમાપ છે. TDD માં નિપુણતા મેળવવાની યાત્રા શિસ્ત અને અભ્યાસની છે.

આજથી જ શરૂ કરો. તમારા આગલા પ્રોજેક્ટમાં એક નાની, બિન-નિર્ણાયક સુવિધા પસંદ કરો અને પ્રક્રિયા માટે પ્રતિબદ્ધ રહો. પહેલા ટેસ્ટ લખો. તેને નિષ્ફળ થતો જુઓ. તેને પાસ કરો. અને પછી, સૌથી અગત્યનું, રિફેક્ટર કરો. ગ્રીન ટેસ્ટ સ્યુટથી આવતા આત્મવિશ્વાસનો અનુભવ કરો, અને તમને ટૂંક સમયમાં આશ્ચર્ય થશે કે તમે ક્યારેય અન્ય કોઈ રીતે સોફ્ટવેર કેવી રીતે બનાવ્યું.